Dr. T's Coding Standard & Tips

Higher level courses such as the Evolutionary Computing course are a great place to sharpen your programming skills by the need to write high-quality code to solve more complex problems than encountered in introductory programming courses. As such, please take some time to read through the section below which corresponds to your preferred programming language. Besides making you a better coder and your code more maintainable, this will also facilitate grading your code, something that will endear you to your TAs which is always a smart thing to do! It will also minimize the risk of losing points related to implementation.

Rules of Thumb

NOTE: These style recommendations supercede all style guides! If you break these rules, then your grade for code style may suffer!

DO Adhere to a Quality Style Guide

You are strongly encouraged to follow the Google C++ Style Guide.

DO Be Consistent in Casing, Indentation, and Brackets

Pick either camel case or lower with underscores. Pick either 2 spaces or 4 spaces or tabs. Pick one way to align brackets. ONE WAY.

// GOOD int generations_survived = 0; double mutation_rate = 0.5; void do_something() { do_something_else(); } void do_something_else() { std::cout << "Hello\n"; }
// BAD int generations_survived = 0; int mutationRate = 0; void do_something() { doSomethingElse(); } void doSomethingElse() { std::cout << "Hello\n"; }

DO NOT Include Types in Variable Names

Best case, this is redundant. Worst case it's a downright lie if you change the type later on.

// GOOD int generation = 0;
// BAD int generation_int = 0; int int_generation = 0; int i_generation = 0;

DO Use Specific Variable / Function Names

If your code looks more like algebra than English, you might be doing it wrong.

// GOOD double mutation_rate = 0; for (Child child : offspring) { do_something(child); } void mutate_child(Child* child) {}
// BAD double mut_rate = 0; double rate = 0; double mr = 0; for (Child i : offspring) { do_something(i); } void mut(Child* child) {}

DO NOT Overuse White Space - Use Between Functions & Logical Breaks

White space should delineate new ideas. Double space English papers, not code.

// GOOD void do_something() { do_something_else(); } void do_something_else() { int x = 3; x++; x *= 4; std::cout << x << '\n'; }
// BAD void do_something() { do_something_else(); } void do_something_else() { int x = 3; x++; x *= 4; std::cout << x << '\n'; }

DO NOT Use Comments for Obvious Code

Code does not lie, but comments can. Also, why waste your own time?

// GOOD double x = y + z;
// BAD // This adds y and z and assigns it to x double x = y + z;

DO Use Comments for Complex / Counter-intuitive Code

Assume the person reading may know less than you.

// GOOD // This dereferences a pointer to the hash map "parents_to_children", // not the value at "primary" *(parents_to_children)["primary"] = 1; // This dereferences a pointer to the value that "primary" maps to *(parents_to_children["primary"]) = 1;
// BAD // Figure it out *(parents_to_children)["primary"] = &value;

DO NOT Copy Paste Near Identical Code - Use Functions!

If you copy and paste and then change one of the copies, you might forget to change the rest of the copies... making your TA's lives miserable.

// GOOD double discriminant(x1, y1, x2, y2) { // x^2 + y^2 where x and y are the differences between points return (x1 * x1 - x2 * x2) + (y1 * y1 - y2 * y2); } double euclidean_distance(x1, y1, x2, y2) { return sqrt(discriminant(x1, y1, x2, y2)); } void main() { double ab_distance = euclidean_distance(ax, ay, bx, by); double ac_distance = euclidean_distance(ax, ay, cx, cy); }
// BAD void main() { double ab_distance = sqrt((ax*ax - bx*bx) + (ay*ay - by*by)); double ac_distance = sqrt((ax*ax - cx*cx) + (ay*ay - cy*cy)); }

DO Use Multiple Files for Your Code

If you write your solutions all in one file, you aren't loving yourself (or your TA's).

DO Adhere to a Quality Style Guide

You are strongly encouraged to follow the Microsoft C# Documentation.

DO Be Consistent in Casing, Indentation, and Brackets

Please follow the casing guidelines provided in the above documentation. This entails using Pascal case for classes and functions and camel case for variables and other keywords.

// GOOD int generationsSurvived = 0; double mutationRate = 0.5; static void DoSomething() { DoSomethingElse(); } static void DoSomethingElse() { Console.WriteLine("Hello"); }
// BAD int generations_survived = 0; int mutationRate = 0; static void do_something() { doSomethingElse(); } static void DoSomethingElse() { Console.WriteLine("Hello"); }

DO NOT Include Types in Variable Names

Best case, this is redundant. Worst case it's a downright lie if you change the type later on.

// GOOD int generation = 0;
// BAD int generationInt = 0; int intGeneration = 0; int iGeneration = 0;

DO Use Specific Variable / Function Names

If your code looks more like algebra than English, you might be doing it wrong.

// GOOD double mutationRate = 0; foreach (Child child in offspring) { DoSomething(child); } public Child MutateChild(Child child) {}
// BAD double mutRate = 0; double rate = 0; double mr = 0; foreach (Child i in offspring) { DS(i); } public Child Mut(Child child) {}

DO NOT Overuse White Space - Use Between Functions & Logical Breaks

White space should delineate new ideas. Double space English papers, not code.

// GOOD static void DoSomething() { DoSomethingElse(); } static void DoSomethingElse() { int x = 3; x++; x *= 4; Console.WriteLine(x); }
// BAD static void DoSomething() { DoSomethingElse(); } static void DoSomethingElse() { int x = 3; x++; x *= 4; Console.WriteLine(x); }

DO NOT Use Comments for Obvious Code

Code does not lie, but comments can. Also, why waste your own time?

// GOOD double x = y + z;
// BAD // This adds y and z and assigns it to x double x = y + z;

DO Use Comments for Complex / Counter-intuitive Code

Assume the person reading may know less than you.

// GOOD // This dereferences a pointer to the hash map "parentsToChildren", // not the value at "primary" *(parentsToChildren).Add("primary", 1); // This dereferences a pointer to the value that "primary" maps to int value = *(parentsToChildren.Get("primary"));
// BAD // Figure it out *(parentsToChildren).Add("primary", &value);

DO NOT Copy Paste Near Identical Code - Use Functions!

If you copy and paste and then change one of the copies, you might forget to change the rest of the copies... making your TA's lives miserable.

// GOOD static double Discriminant(x1, y1, x2, y2) { // x^2 + y^2 where x and y are the differences between points return (x1 * x1 - x2 * x2) + (y1 * y1 - y2 * y2); } static double EuclideanDistance(x1, y1, x2, y2) { return Math.Sqrt(Discriminant(x1, y1, x2, y2)); } static void Main(string[] args) { double abDistance = EuclideanDistance(ax, ay, bx, by); double acDistance = EuclideanDistance(ax, ay, cx, cy); }
// BAD static void Main(string[] args) { double abDistance = Math.Sqrt((ax*ax - bx*bx) + (ay*ay - by*by)); double acDistance = Math.Sqrt((ax*ax - cx*cx) + (ay*ay - cy*cy)); }

DO Use Multiple Files / Classes for Your Code

If you write your solutions all in one file, you aren't loving yourself (or your TA's).

DO Adhere to a Quality Style Guide

You are strongly encouraged to follow the Google Java Style Guide.

DO Be Consistent in Casing, Indentation, and Brackets

Pick either camel case or lower with underscores. Pick either 2 spaces or 4 spaces or tabs. Pick one way to align brackets. ONE WAY.

// GOOD int generationsSurvived = 0; double mutationRate = 0.5; static void doSomething() { doSomethingElse(); } static void doSomethingElse() { System.out.println("Hello"); }
// BAD int generations_survived = 0; int mutationRate = 0; static void do_something() { doSomethingElse(); } static void doSomethingElse() { System.out.println("Hello"); }

DO NOT Include Types in Variable Names

Best case, this is redundant. Worst case it's a downright lie if you change the type later on.

// GOOD int generation = 0;
// BAD int generationInt = 0; int intGeneration = 0; int iGeneration = 0;

DO Use Specific Variable / Function Names

If your code looks more like algebra than English, you might be doing it wrong.

// GOOD double mutationRate = 0; for (Child child : offspring) { doSomething(child); } public Child mutateChild(Child child) {}
// BAD double mutRate = 0; double rate = 0; double mr = 0; for (Child i : offspring) { doSomething(i); } public Child mut(Child child) {}

DO NOT Overuse White Space - Use Between Functions & Logical Breaks

White space should delineate new ideas. Double space English papers, not code.

// GOOD static void doSomething() { doSomethingElse(); } static void doSomethingElse() { int x = 3; x++; x *= 4; System.out.println(x); }
// BAD static void doSomething() { doSomethingElse(); } static void doSomethingElse() { int x = 3; x++; x *= 4; System.out.println(x); }

DO NOT Use Comments for Obvious Code

Code does not lie, but comments can. Also, why waste your own time?

// GOOD double x = y + z;
// BAD // This adds y and z and assigns it to x double x = y + z;

DO Use Comments for Complex / Counter-intuitive Code

Assume the person reading may know less than you.

// GOOD // This selects the third child at depth 3 in a serialized binary tree of // children Child[] childrenTree = new Child[256]; Child selectedChild = childrenTree[(1 << 3) + 1]; mutateChild(selectedChild);
// BAD // Figure it out Child[] childrenTree = new Child[256]; Child selectedChild = childrenTree[(1 << 4) + 5]; mutateChild(selectedChild);

DO NOT Copy Paste Near Identical Code - Use Functions!

If you copy and paste and then change one of the copies, you might forget to change the rest of the copies... making your TA's lives miserable.

// GOOD static double discriminant(x1, y1, x2, y2) { // x^2 + y^2 where x and y are the differences between points return (x1 * x1 - x2 * x2) + (y1 * y1 - y2 * y2); } static double euclideanDistance(x1, y1, x2, y2) { return Math.sqrt(discriminant(x1, y1, x2, y2)); } static void Main(String[] args) { double abDistance = euclideanDistance(ax, ay, bx, by); double acDistance = euclideanDistance(ax, ay, cx, cy); }
// BAD static void Main(String[] args) { double abDistance = Math.sqrt((ax*ax - bx*bx) + (ay*ay - by*by)); double acDistance = Math.sqrt((ax*ax - cx*cx) + (ay*ay - cy*cy)); }

DO Use Multiple Files / Classes for Your Code

If you write your solutions all in one file, you aren't loving yourself (or your TA's).

DO Adhere to a Quality Style Guide

You are strongly encouraged to follow the Python PEP 8 Style Guide.

DO Be Consistent in Casing, Indentation, and Brackets

Pick either camel case or lower with underscores. Use Pascal case for classes. Pick either 2 spaces or 4 spaces or tabs (luckily Python won't let you use a mixture). PICK ONE.

# GOOD generations_survived = 0 mutation_rate = 0.5 def do_something(): do_something_else() def do_something_else(): print("Hello") # This is Pascal case class MyClass(object): pass
# BAD generations_survived = 0 mutationRate = 0 def do_something() doSomethingElse() # This will actually cause an error def doSomethingElse() print("Hello") # This is NOT Pascal case class my_class(object): pass

DO NOT Include Types in Variable Names

Best case, this is redundant. Worst case it's a downright lie if you change the type later on. Also, how dare you defile such a beautiful untyped language with your filthy types!

# GOOD generation = 0
# BAD generation_int = 0 int_generation = 0 i_generation = 0

DO Use Specific Variable / Function Names

If your code looks more like algebra than English, you might be doing it wrong.

# GOOD mutation_rate = 0 for child in offspring: do_something(child) def mutate_child(child): pass
# BAD mutRate = 0 rate = 0 mr = 0 for i in offspring: doSomething(i) def mut(child): pass

DO NOT Overuse White Space - Use Between Functions & Logical Breaks

White space should delineate new ideas. Double space English papers, not code.

# GOOD def do_something(): do_something_else() def do_something_else(): x = 3 x += 1 x *= 4 print(x)
# BAD def do_something(): do_something_else() def do_something_else(): x = 3 x += 1 x *= 4 print(x)

DO NOT Use Comments for Obvious Code

Code does not lie, but comments can. Also, why waste your own time?

# GOOD x = y + z
# BAD # This adds y and z and assigns it to x x = y + z

DO Use Comments for Complex / Counter-intuitive Code

Assume the person reading may know less than you.

# GOOD # This populates a dictionary with the alphabet as the keys and numbers 0 thru # 25 as the values alphabet_to_index = { chr(i): i for i in range(65, 91) }
// BAD # Figure it out cool_map = { (i, j): (i+j)**2 for i in range(10) for j in range(10) }

DO NOT Copy Paste Near Identical Code - Use Functions!

If you copy and paste and then change one of the copies, you might forget to change the rest of the copies... making your TA's lives miserable.

# GOOD def discriminant(x1, y1, x2, y2): # x^2 + y^2 where x and y are the differences between points return (x1**2 - x2**2) + (y1**2 - y2**2) def euclidean_distance(x1, y1, x2, y2): return math.sqrt(discriminant(x1, y1, x2, y2)) def main(): ab_distance = euclidean_distance(ax, ay, bx, by) ac_distance = euclidean_distance(ax, ay, cx, cy)
# BAD def main(): ab_distance = math.sqrt((ax**2 - bx**2) + (ay**2 - by**2)) ac_distance = math.sqrt((ax**2 - cx**2) + (ay**2 - cy**2))

DO Use Multiple Files / Classes for Your Code

If you write your solutions all in one file, you aren't loving yourself (or your TA's).

For those of you programming in Python, you should write your code "The Pythonic Way." Alas, this way of writing code is more of a culture than a strict standard and the closest thing to a guide may be the Zen of Python